1. Field of the Invention
The invention relates generally to network security. More particularly, the invention relates to a method and system for trust-based, fine-grained rate limiting of network requests.
2. Description of Related Technology
A fundamental feature of current network technologies is the provision of network services to individual users by furnishing each user an account. Users then request services through their accounts by logging into a server using a client. In current usage, the term ‘client’ may refer either to the software application by which a user accesses the network resources provided from the server, or the machine that is running the client software. To guarantee that the party attempting to gain access to an account is actually the rightful accountholder, access is controlled through an authentication process, in which the account holder is required to provide one or more pieces of information, known only to the account holder, before he is granted access to network services. Typically, authentication requires provision of a user ID and a password. User accounts are seen in most network environments, e.g. local area networks limited to a small company, as well as in ISP's (Internet service provider) having tens of millions of subscribers. Unfortunately, individuals wishing to make unauthorized use of another's user account are common, and thus password theft has become widespread.
Password theft is a serious problem, frustrating users' expectations of trust, safety, security, and privacy, and interfering with the efforts of ISP's to meet those expectations. While password theft is often involved in particularly serious crimes, such as computer vandalism or identity theft, one of the main motives for password theft is to co-opt user accounts for the sending of ‘spam,’ i.e. unsolicited e-messages that are sent to many recipients at one time, usually to promote a product or service. Most users find spam annoying and intrusive, but it can also be highly offensive, as when one receives spam that advertises web sites that distribute pornography. Furthermore, large volumes of spam severely burden network infrastructures. Thus, control of password theft constitutes an important measure in reducing the volume of spam. A large ISP may have to reset thousands of accounts per week because of stolen passwords, at a cost of several million dollars per year.
Passwords can be compromised in a number of ways. Users often keep their passwords written on easily found POST-IT NOTES (3M Corporation, St. Paul Minn.) or scraps of paper, instead of committing them to memory; or they may disclose their passwords to friends and co-workers. Often, users are enticed into revealing their user names and passwords via email, instant messaging or by visiting spurious web sites. Additionally, users may be tricked into downloading and installing Trojan horse programs, i.e. keystroke monitoring software that sniffs for typed passwords and subsequently sends them to a hacker. Finally, cracking, guessing a user's password through repeated login attempts, is very common. Generally, cracking is done by means of a software program that iteratively tries one alphanumeric combination after another, until it guesses a user's password.
Crackers generally launch either brute force or dictionary attacks. During a brute force attack, in which the attacker has no previous knowledge of what a password is likely to be, the cracker iteratively tries all possible alphanumeric combinations, starting with one character, and then proceeding to combinations of two characters and so on. A brute force attack typically requires large amounts of computing power. For example, if an attacker were going to attempt cracking all possible six-character passwords composed of the upper-case letters, the lower-case letters and the digits 0-9, there would be about 56,800,000,000 possibilities. Even a powerful computer would require at least several weeks of continuous operation to complete the task. For this reason, brute force attacks are relatively uncommon.
Much more efficient, and more common, are dictionary attacks, in which only words from the dictionary, for example, are tested as passwords. While the total number of words in the English language numbers a few million, there are no more than two hundred thousand words in common use. Thus, a computer capable of trying five thousand passwords per second could try the entire two hundred thousand words in less than a minute. Similarly, the cracker could make guesses based on names, slang, science fiction shows and books, technical jargon and so forth. It is much easier to take a limited set of words and try combinations based on the known set than it is to crack by brute force.
Most efficient is a rule-based attack, in which the attacker has some knowledge of one or more rules used to generated passwords. For example, a password may consist of a word followed by a one or two digit number, e.g. user1, mind67. The cracker then generates passwords according to the rule.
In actuality, most crackers seek to crack the password for a large set of user ID's, for example the passwords of any of the millions of AOL (TIME-WARNER, INCORPORATED) user IDs, rather than try to crack a particular user ID's password. Because many users use one of several simple, common passwords, “abc” or “password,” for example, the usual cracking technique is to select such a common password and then iterate through a list of known or generated user IDs, trying each user ID against the common password until a user ID is found that uses the common password. Thus, it is more typical for crackers to guess a user ID matching a chosen password than to guess the password matching a chosen user ID.
For the cracker to target a given service, such as AOL's login servers, the targeted service must offer a higher return, in terms of number of cracked accounts times the value of each cracked account to the cracker, than another service would. This is because a cracker's resources are limited. By reducing the rate at which a cracker is able to crack user accounts, a service can reduce the cracker's return. Any reduction in cracked accounts provides a number of benefits to the service operator, among them reducing the cost of recovering compromised accounts and the cost of handling spam emails sent from them. Additionally, if the service operator can sufficiently reduce the rate at which accounts are cracked, it should be possible to get the cracker to shift his cracking resources to other, easier targets, and thereby achieve a savings in number of cracked accounts far beyond that achievable through rate limiting alone.
The cracker typically needs to guess possible user ID/password pairs at a very high rate to crack enough accounts to support his spamming or other account-abusing activities. On the other hand, server technology has evolved to help meet threats of this type. Servers and routers have the ability to monitor inbound and outbound traffic flows. A server monitors inbound traffic, for example, by tracking the number of packets per second or bytes per second received, perhaps at a selected port, or from a selected network address. As the number of packets or bits per second in a stream increases, the stream consumes more of the server's bandwidth. To apportion bandwidth appropriately, servers and routers have traffic management capabilities, commonly called rate limiting, which include traffic policing measures. Using rate limiting measures, a server manages inbound and outbound traffic according to preconfigured rate policies that enforce bandwidth limits. Rate policies can be configured for various interfaces such as individual ports or trunk groups. Additionally, rate policies can be configured for various types of traffic, for example a specific MAC (media access control) address, or specific TCP (transmission control protocol), or UDP (user datagram protocol) ports.
At its finest granularity, rate limiting is applied to specific source IP (internet protocol) addresses. In this way, a server can detect traffic coming from a particular IP address that exceeds the bandwidth allocated by the rate policy. Thus, servers recognize atypical traffic and apply rate limiting countermeasures immediately. For example, a cracker may mount an attack from behind a particular IP address, perhaps behind a proxy server or a firewall, directing requests to the server at a rate that exceeds the allocated bandwidth. The server then limits the rate at which requests are processed from the particular IP address by limiting the bandwidth to that allocated by the rate policy. Additionally, if the traffic exceeds a certain pre-configured rate, the server may drop the traffic entirely. Thus, by imposing rate limiting countermeasures, a server can fend off, or at least, badly frustrate attacks by crackers.
However, a fundamental limitation of IP-address based rate limiting is that a peer IP address is a very weak proxy for a particular user using a particular PC, and hence IP-address based rate limiting is a very blunt and imprecise tool. A counter measure applied to a suspicious IP address can be a draconian measure. Even though each client machine has it's own local IP address, in many cases the internet traffic from these client machines is routed through an intermediary device, such as a firewall or a web proxy server, and it is the IP address of this intermediary device, rather than that of the individual client machine, that is seen as the requesting IP address by the destination network server. Thus, rate limiting traffic from the IP address of the intermediary device effectively denies or limits service to all users whose requests originate from the suspicious IP address, even though the actual target may be a single cracker among them. Thus, by using the peer (requestor's) IP address alone, the network server has no ability to discern which particular client machine made a given request when it is routed through a shared intermediary device. Further, a given user's peer IP address may change from session to session or even from network request to network request. In this case, applying rate limiting to a peer IP address may have no effect on the targeted user.
It would be a great advance in the art to provide a method of fine-grained rate limiting, in which individual user ID/machine combinations could be distinguished and separately rate-limited even when sharing the same peer IP address.
K. Shin, K. Kobayashi, T. Aratani, Device and method for authenticating access rights to resources, U.S. Pat. No. 5,987,134 (Nov. 16, 1999) provides an approach that requires several different components including challenging data, user identifying information, and an access ticket. Shin, et al. are primarily concerned with authenticating a user, rather than establishing a particular piece of hardware as trusted.
M. Ensor, T. Kowalski, A. Primatic, User-transparent Security method and apparatus for authenticating user terminal access to a network, U.S. Pat. No. 5,721,780 (Feb. 24, 1998) describe a method and apparatus for implementing security in data and telecommunications networks that is independent of and transparent to users. When a user terminal connects to a network control center, the network control center generates an encrypted password based on the user terminal's network coupling identifier. The password is downloaded to the terminal and simultaneously saved by the network control center. Subsequently, when a user attempts to access the network, the network control center retrieves the password from the terminal and compares it with the stored copy. If there is a match, network access is granted. With each logon from the terminal, a new password is generated and downloaded to the user terminal. The exchange of passwords described by Ensor, et al. allows a user terminal to be established as trusted on a session-by-session basis. However, the trust is only machine-specific; it is not specific to the user as well. Furthermore, Ensor, et al. fail to contemplate fine-grained rate limiting based on designating a machine as trusted by issuing a trust token.
K. Seamons, W. Winsborough, Trust negotiation in a client/server data processing network using automatic incremental credential disclosure, U.S. Pat. No. 6,349,338 (Feb. 19, 2002) describe a system in which trust is negotiated between two unfamiliar data processing apparatus by incrementally exchanging credentials. Providing multiple opportunities for exchange of credentials makes it possible to negotiate a higher level of trust between two machines previously unfamiliar with each other than a single exchange of credentials. The approach provided by Seamons, et al. involves the iterative exchange of credentials and credential access policies, wherein the credentials are primarily issued by various third parties and describe the holder of the credential.
Siebel 7 Integration with Baltimore SelectAccess 5.0: Technical information brief describes the use of a trust token to provide SSO (single sign-on) functionality across several applications in different domains. Similarly, R. Zuccherato, Authentication token (Nov. 6, 2002) describes an authentication token that is issued by an authentication server for later use in authenticating to a different application server. There is no teaching in either source of the use of a trust token to designate a particular machine/user combination as trusted, or differentially applying rate limiting countermeasures based on the presence or absence of a trust token.
It would be highly advantageous to be able to distinguish friendly network traffic from hostile network traffic at the granularity of a single user ID/machine combination. It would be further advantageous to reduce the rate at which legitimate users are denied service from a server while thwarting attackers operating from behind the same IP address as legitimate users. It would be a still further advantage to improve server defenses and reduce the volume of spam sent and received by network subscribers by implementing a method of fine-grained, trust-based rate limiting.